Filesystem is all my need
我还在纠结，在我的个人系统中，该如何存储数据。
之前我曾构思了 MinIO + MongoDB 的方案，并基于 Docker 进行部署。但实际进展相当缓慢，这让我意识到，也许这个方案不适合自己。
我很忙，也很懒
当我着手开发一套大系统时，我发现，它会长久地侵占我的时间，导致没有时间做其它事情。
更加地，我不确定它能把我带向哪里？这套大系统会让我的生活更好吗？还是产生了一个妖怪，将我吞噬？
如果说，我想开发一个系统，帮助我更好地读书。但是为了开发这个系统，我在两年内都没有时间读书，这就有问题了。
基于文件系统的笔记软件
在过往地实践中，我不止一次选择文件系统存储数据。
比如，我曾经开发过一款“笔记”软件，它只包含一个 Qt 的 Filesystem Tree Widget。只有分类目录功能，完全没有笔记书写功能。
这款软件我使用了好几年，那几年也是我成长飞快的几年，这个软件很好地支撑了我。
它有不少有意思的功能：
- 本地“图床”：编写 Markdown 时，插入图片是个麻烦事。很多人会选择上传图床。可图床作为在线服务，未来有很大可能关闭。我在软件里加了个按钮，将图片“上传到”本地目录，并生成相对路径。解决了图片插入的问题。
- 复用 Typora：Typora 是我用过最好的笔记软件。我知道自己如果重写一个，绝对没有这么好，倒不如双击树状图节点，直接在 Typora 里编辑。
最强大的一点，在于数据迁移的时候。这个软件后来我没再用了，将笔记库拷贝到优盘，这是一份非常规整、十分便于查阅的资料，甚至在后续迁移时也非常方便。
总之，这是我从文件系统中尝到的一大甜头。
管理电子书
文件系统也有很大的局限性。以我进行电子书管理的经验为例。
曾经很长时间，我管理电子书就是创建层级的子目录。非常简单方便。不需要任何第三方软件，直接用系统的文件管理器即可。
书库的复制、迁移甚至合并都很方便。我发现，只要基于文件系统，我的实践都能维持相当长一段时间。
我同时也发现，纯基于文件系统，我也终将会抛弃它。
文件系统+元信息
我的笔记系统几经辗转，迁移到 0.0 Obsidian 介绍。书库也几经辗转迁移到 Calibre。
它们的共同点在于，还是基于文件系统，但都添加了数据库，给文件加上了元信息。
有了0.0 Obsidian 介绍，我再也回不去之前的文件树笔记软件。
有了Calibre，尽管它的文件系统布局有点奇怪，但自己也回不到文件系统的文件夹管理了。
纯粹的文件系统软件
对于 Calibre 的文件系统布局，我还是十分介意。尽管原作者说，他有充分的里有，按照这种布局管理的效率是最高的。但是，离开了 Calibre，真的很难看。
这让我想到曾经使用一个开源图片管理软件的经历。
那时，我刚淘来一个矿渣蜜獾超存，用 OpenMediaVault 搭建了一个 NAS，插了三块西数紫盘，没有用 RAID，而是自己配了个三个盘依次 rsync 的同步算法。最终，我信誓旦旦，这就是我未来所有数据的可靠容器了。（不到一年后我就换成群晖了。）
图片管理软件就发生在这时。我找到一款当时比较好的图片管理软件，用 Docker 部署在蜜獾超存上，把一部分珍贵照片存在上面。
这款软件是一个典型的 PHP 应用，它会在文件系统中，对照片预先生成不同尺寸的预览图。
于是，当我想从文件系统中，将这部分珍贵照片迁走时，我得到了一大堆大大小小的预览图。至于原图在哪里，我还得花费一番心思去研究。
相比之下，0.0 Obsidian 介绍 就是一款纯粹的文件系统软件，因为它是以文件系统布局优先的。如果未来有一天，不再用这款软件，剩下的数据依旧是优雅的。
而 Calibre 就不够纯粹，离开了的 Calibre 数据库，文件系统里的书籍将变成一团乱麻。
注：开发一款纯粹的文件系统的书库软件，也许是一个好的灵感。
总结
复杂的方案，对于我来说，实在是过于沉重。
文件系统的简单、简洁，更适合于我。
至于文件系统缺乏元信息的缺点，可以采用元信息文件，加上本地建立索引数据库的方式，进行补充。
本文作者：Maeiee
本文链接：Filesystem is all my need
版权声明：如无特别声明，本文即为原创文章，版权归 Maeiee 所有，未经允许不得转载！
喜欢我文章的朋友请随缘打赏，鼓励我创作更多更好的作品！
